Before describing the trusted Web site support we must explain why we need it and why it is useful.

Users need single sign-on.

To support single sign-on in a "classical" architecture where each application has it own realm and authentication, designers must put gateways in place with a mapping mechanism.

This design has the following drawbacks:

1. One authentication database to maintain per application

2. One mapping table to maintain per application pair

3. Gateways and application authentication to implement

Despite its drawbacks this design can be the only solution when you must integrate existing applications with their own authentication mechanism and thin-grained authorizations. For instance on the diagram above Application 1 and Application 2 protect their resources with Access Control Lists (ACLs). Application administrators can move users from one group to another and grant permissions to groups and users.

Most of the time at least for new application sets such complicated solutions are not needed. Let’s take the example of the Pandora architecture:

The authentication application collects information allowing charging and delivering the good.

Pandora forwards this information but doesn’t use it. Payment and delivery data are what we call MacGuffin data. MacGuffin is a major contribution of Alfred Hitchcock to science. In a film a MacGuffin is something that the characters worry about but the audience (and the scenarist and director) does not. In an application a MacGuffin data is something that maybe matters for the actor and for the partnering applications but not for the application itself.

Pandora needs two things:

1. To trust the authentication application: if it has logged on the Authentication application the customer can use Pandora

2. To be sure that the payment and delivery data are valid

Maybe Application 2 has a more demanding security. Application 2 can implement ACLs and define three or four groups of users but once again Application 2 doesn’t need to know the customer identity. Application 2 only needs to know which group the customer belongs to.

We believe that it is a general rule:

• User data are MacGuffin data for most applications

• Most applications only need to know if the user is authenticated and maybe in which group the user is authenticated

Note:

Another strong point of this design is the support of many authentication servers.

Let’s consider the case of an organization that has for historical and management reasons an authentication server for its internal users, another authentication server for its partners and a third one for its customers. All authentication servers can link to some applications with different profiles. The internal users’ and the partners’ authentication servers can link to some other applications and only the internal users’ authentication server can link to the remaining applications.

When a user authenticates on an Application server the Application server records the user context in memory and writes a context identifier in a cookie sent to the browser with the HTTP response. When the user makes another request on the same Application server the Application server receives the cookie with the HTTP request and can retrieve the user context. It is important to note that:

1. The context identifier is stored in a cookie on the browser

2. The cookie is site dependent

A trusted site support requires:

1. A multi-site support. The site B must trust an authentication that took place on site A.

2. That site B can check that the request is coming from site A

To address the first requirement we simply need to code a dynamic link on a JSP page of site A that carries user information from site A to site B:

The code contains three sections:

1. A link: instead linking to a page the anchor element calls a script called goto

2. A goto script: this script submits a HTTP post to the parameter page

3. The hidden form submitted by the script

The code calls a link bean (lb) JavaBean:

Site B implements an entry page for each user group. The link bean analyzes the user credentials in the context of site A to determine in which group the user should be defined on site B and eventually find out to which page the user should link. Its getLinkPage method returns that link.

In the getUserInfo method the link bean extracts the MacGuffin data from site A.

The site B entry pages:

1. Retrieve the user data from the request

2. Store the user data in a Session attribute. Therefore when a subsequent page of site B needs to call a third site that needs the user data it still can send the data.

3. Authenticate if needed

Site B must check that the request is coming from a valid referrer site.

The most reliable solution consists in using a certificate.

Site A

1. Generates a public/private key pair

2. Requires a certificate for its public key to a certificate authority trusted by Site B

3. Signs the user data with its private key

4. Sends the certificate and the signature along with the user data to site B

Assuming that the link bean implements signature details the link page has only minor changes:

The link bean implements two new methods:

1. getCertificate that returns Site A certificate

2. getSignature that returns the signature of the user data with the Site A private key

The site B entry pages get the certificate and signature along with the user data from the request. Entry pages check:

1. With the public key embedded in the certificate that the signature was made with the user data and the corresponding private key

2. That the certificate was issued by a valid certificate authority

3. That the certificate was not revoked by checking the Certificate Revocation Lists (CRLs) of the certificate authority

For the implementation details look at the Pandora implementation document and sources. For background information about security programming in Java you can also look at our article in the May 2001 issue of Java Developer Journal.

Contact:support@pagebox.net
©2002-2004 Alexis Grandemange. Last modified .